Real time electronic commerce telecommunication system and method

ABSTRACT

An auction system and method, which identifies at least one lot to be auctioned, having a plurality of units within the lot and associated auction parameters; transmits a remaining quantity of units within the lot from a central server to a plurality of remote locations; receives bid identifications for remaining units within the lot at the contemporaneous offering price from the plurality of remote locations; and decrements the offering price over time. The decrement may be adaptive to a bid activity pattern, and the bid activity pattern may be stored in a database. A local server may be provided to communicate between the central server and remote locations while changing the format of the information communicated. The packets preferably include compressed information, and preferably include quantity remaining information for a plurality of auction lot.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a Continuation of U.S. patent applicationSer. No. 13/494,793, filed Jun. 12, 2012, now U.S. Pat. No. 8,595,087,issued Nov. 26, 2013, which is a Continuation of U.S. patent applicationSer. No. 12/984,361, filed Jan. 4, 2011, now U.S. Pat. No. 8,200,547,issued Jun. 12, 2012, which is a Continuation of U.S. patent applicationSer. No. 09/767,126, filed Jan. 22, 2001, now U.S. Pat. No. 7,865,420,issued Jan. 4, 2011, which claims priority from U.S. Provisional PatentApplication Nos. 60/177,154, filed Jan. 20, 2000, and 60/178,628, filedJan. 28, 2000, the entirety of which are each expressly incorporatedherein by reference.

FIELD OF THE INVENTION

The present invention relates to the field of transaction processingnetworks including electronic commerce systems and methods, and moreparticular to those employing client-server architectures. The presentinvention also relates to electronic auction systems and methods, forexample providing real time performance through switched packetnetworks.

BACKGROUND OF THE INVENTION Internet

The Internet is structured such various networks are interconnected,with communications effected by addressed packets conforming to a commonprotocol. Based on the packet addressing, information is routed fromsource to destination, often through a set of networks having multiplepotential pathways. The communications medium is shared between allusers. Statistically, some proportion of the packets are extraordinarilydelayed, or simply lost. Therefore, protocols involving communicationsusing these packets include error detection schemes that request aretransmit of required data not received within a time window. In theeven that the network nears capacity or is otherwise subject to limitingconstraint, the incidence of delayed or lost packets increases, therebyincreasing requests for retransmission and retransmission. Therefore, asthe network approaches available bandwidth, the load increases,ultimately leading to failure. In instances where a minimum quality ofservice must be guaranteed, special Internet technologies are required,to reserve bandwidth or to specify network pathways. End-to-end qualityof service guarantees, however, may exceed the cost of circuit switchedtechnologies, such as dialup modems, especially where the high qualityneeds are intermittent.

Internet usage typically involves an Internet server, an automatedsystem capable of responding to communications received through theInternet, and often communicating with other systems not directlyconnected to the Internet. The server typically has relatively largebandwidth to the Internet, allowing multiple simultaneous communicationssessions, and usually supports the hypertext transport protocol (HTTP),which provides, in conjunction with a so-called web browser on a remoteclient system, a human readable interface which facilitates navigationof various resources available in the Internet. The client systems aretypically human user interfaces, which employ a browser to display HTTP“web pages”. The browser typically does not provide intelligence.Bandwidth between the client and Internet is typically relatively small,and various communications and display rendering considered normal.Typically, both client and server are connected to the Internet throughInternet service providers, each having its own router.

It is also known to provide so-called proxy servers and firewalls, whichare automated systems that insulate the client system from the Internet.Further, so-called Internet applications and applets are known whichprovide local intelligence at the client system. Further, it is known toprovide a local server within the client system for locally processing aportion of the information. These local servers, applications andapplets are non-standard, and thus require special software to beavailable locally for execution.

Thus, the Internet poses a number of advantages for commercial use,including low cost and ubiquitous connectivity. Therefore, it isdesirable to employ standard Internet technologies while achievingsufficient quality communications to effect an efficient transaction.

Electronic Commerce

There is presently a high degree of interest in employing the Internet,an international set of interconnected networks with uniform protocolsand addressing schemes, for conducting commercial transactions.Implementations of so-called e-commerce systems raise many issuesdistinct from personal contact business relationships. Further, thegrowing prominence of electronic commerce is altering the conduct ofdiverse businesses, even those that do not directly conduct businesstransactions on-line.

Further, traditional Internet e-commerce systems require a substantialamount of information to be communicated, both to inform the potentialbidder of the nature and quantity of goods available for auction, and toidentify and submit an offer. In secure systems, an additional layer ofoverhead is generated, increasing traffic volume and communicationsprocessing for both sender and receiver.

Market Economy Systems

In modern retail transactions, predetermined price transactions arecommon, with market transactions, i.e., commerce conducted in a settingwhich allows the transaction price to float based on the respectivevaluation allocated by the buyer(s) and seller(s), often left tospecialized fields. While interpersonal negotiation is often used to seta transfer price, this price is often different from a transfer pricethat might result from a best-efforts attempt at establishing a marketprice. Assuming that the market price is optimal, it is thereforeassumed that alternatives are sub optimal. Therefore, the establishmentof a market price is desirable over simple negotiations.

One particular problem with market-based commerce is that both selleroptimization and market efficiency depend on the fact thatrepresentative participants of a preselected class are invited toparticipate, and are able to promptly communicate, on a relevanttimescale, in order to accurately value the goods or services and makean offer. Thus, in traditional market-based system, all participants arein the same room, or connected by a high quality telecommunicationslink. Alternately, the market valuation process is prolonged over anextended period, allowing non-real time communications of marketinformation and bids. Thus, attempts at ascertaining a market price fornon-commodity goods can be subject to substantial inefficiencies, whichreduce any potential gains by market pricing. Further, while marketpricing might be considered “fair”, it also imposes an element of risk,reducing the ability of parties to predict future pricing and revenues.Addressing this risk may also reduce efficiency of a market-basedsystem.

Auction Systems

When a single party seeks to sell goods to the highest valuedpurchaser(s), to establish a market price, the rules of conducttypically define an auction. Typically, known auctions provide anascending price or descending price over time, with bidders makingoffers or ceasing to make offers, in the descending price or ascendingprice models, respectively, to define the market price. Afterdetermining the winner of the auction, the pricing rules define uniformprice auctions, wherein all successful bidders pay the lowest successfulbid, second price auctions wherein the winning bidder pays the amountbid by the next highest bidder, and pay-what-you-bid auctions. Thepay-what-you-bid auction is also known as a discriminative auction whilethe uniform price auction is known as a non-discriminative auction. In asecond-price auction, also known as a Vickrey auction, the policy seeksto create a disincentive for speculation and to encourage bidders tosubmit bids reflecting their true value for the good. In the uniformprice and second price schemes, the bidder is encourages to disclose theactual private value to the bidder of the good or service, since at anyprice below this amount, there is an excess gain to the buyer, whereasby withholding this amount the bid may be unsuccessful, resulting in aloss of the presumably desirable opportunity. In the pay-what-you-bidauction, on the other hand, the buyer need not disclose the maximumprivate valuation, and those bidders with lower risk tolerance will bidhigher prices. See, www.isoc.org/inet98/proceedings/3b/3b_(—)3.html;www.ibm.com/iac/reports-technical/reports-bus-neg-internet.html.

Two common types of auction are the English auction, which sells asingle good to the highest bidder in an ascending price auction, and theDutch auction, in which multiple units are available for sale, and inwhich a starting price is selected by the auctioneer, which issuccessively reduced, until the supply is exhausted by bidders (or theminimum price/final time is reached), with the buyer(s) paying thelowest successful bid. The term Dutch auction is also applied to a typeof sealed bid auction. In a multi-unit live Dutch auction, eachparticipant is provided with the current price, the quantity on hand andthe time remaining in the auction. This type of auction, typically takesplace over a very short period of time and there is a flurry of activityin the last portion of the auction process. The actual auctionterminates when there is no more product to be sold or the time periodexpires.

In selecting the optimal type of auction, a number of factors areconsidered. In order to sell large quantities of a perishable commodityin a short period of time, the descending price auctions are oftenpreferred. For example, the produce and flower markets in Hollandroutinely use the Dutch auction (hence the derivation of the name),while the U.S. Government uses this form to sell its financialinstruments. The format of a traditional Dutch auction encourages earlybidders to bid up to their “private value”, hoping to pay some pricebelow the “private value”. In making a bid, the “private value” becomesknown, helping to establish a published market value and demand curvefor the goods, thus allowing both buyers and sellers to definestrategies for future auctions.

In an auction, typically a seller retains an auctioneer to conduct anauction with multiple buyers. (In a reverse auction, a buyer solicitsthe lowest price from multiple competing vendors for a desiredpurchase). Since the seller retains the auctioneer, the selleressentially defines the rules of the auction. These rules are typicallydefined to maximize the revenues or profit to the seller, whileproviding an inviting forum to encourage a maximum number of high valuedbuyers. If the rules discourage high valuations of the goods orservices, or discourage participation by an important set of potentialbidders, then the rules are not optimum. A rule may also be imposed toaccount for the valuation of the good or service applied by the seller,in the form of a reserve price. It is noted that these rules typicallyseek to allocate to the seller a portion of the economic benefit thatwould normally inure to the buyer, creating an economic inefficiency.However, since the auction is to benefit the seller, not society as awhole, this potential inefficiency is tolerated. An optimum auction thusseeks to produce a maximum profit (or net revenues) for the seller. Anefficient auction, on the other hand, maximizes the sum of the utilitiesfor the buyer and seller. It remains a subject of academic debate as towhich auction rules are most optimum in given circumstances; however, inpractice, simplicity of implementation may be a paramount concern, andsimple auctions may result in highest revenues; complex auctions, whiletheoretically more optimal, may discourage bidders from participating orfrom applying their true and full private valuation in the auctionprocess.

Typically, the rules of the auction are predefined and invariant.Further, for a number of reasons, auctions typically apply the samerules to all bidders, even though, with a priori knowledge of theprivate values assigned by each bidder to the goods, or a prediction ofthe private value, an optimization rule may be applied to extract thefull value assigned by each bidder, while selling above the sellersreserve.

In a known ascending price auction, each participant must be made awareof the status of the auction, e.g., open, closed, and thecontemporaneous price. A bid is indicated by the identification of thebidder at the contemporaneous price, or occasionally at any price abovethe minimum bid increment plus the previous price. The bids areasynchronous, and therefore each bidder must be immediately informed ofthe particulars of each bid by other bidders.

In a known descending price auction, the process traditionally entails acommon clock, which corresponds to a decrementing price at eachdecrement interval, with an ending time (and price). Therefore, onceeach participant is made aware of the auction parameters, e.g., startingprice, price decrement, ending price/time, before the start of theauction, the only information that must be transmitted is auction status(e.g., inventory remaining).

As stated above, an auction is traditionally considered an efficientmanner of liquidating goods at a market price. The theory of an auctionis that either the buyer will not resell, and thus has an internal orprivate valuation of the goods regardless of other's perceived values,or that the winner will resell, either to gain economic efficiency or asa part of the buyers regular business. In the later case, it is ageneral presumption that the resale buyers are not in attendance at theauction or are otherwise precluded from bidding, and therefore that,after the auction, there will remain demand for the goods at a price inexcess of the price paid during the auction. Extinction of this residualdemand results in the so-called “winner's curse”, in which the buyer canmake no profit from the transaction during the auction. Since thisdetracts from the value of the auction as a means of conductingprofitable commerce, it is of concern to both buyer and seller. In fact,experience with initial public offerings (IPOs) of stock through variousmeans has demonstrated that by making stock available directly to allclasses of potential purchasers, latent demand for a new issue isextinguished, and the stock price is likely to decline after issuance,resulting in an IPO which is characterized as “unsuccessful”. Thispotential for post IPO decline tempers even initial interest in theissue, resulting in a paradoxical decline in revenues from the vehicle.In other words, the “money on the table” resulting from immediateretrading of IPO shares is deemed a required aspect of the IPO process.Thus, methods that retain latent demand after IPO shares result in postIPO increases, and therefore a “successful” IPO. Therefore, where thetransaction scheme anticipates demand for resale after the initialdistribution, it is often important to assure a reasonable margin forresellers and limitations on direct sale to ultimate consumers.

Research into auction theory (game theory) shows that in an auction, thegoal of the seller is to optimize the auction by allocating the goodsinefficiently, and thus to appropriate to himself an excess gain. Thisinefficiency manifests itself by either withholding goods from themarket or placing the goods in the wrong hands. In order to assure forthe seller a maximum gain from a misallocation of the goods,restrictions on resale are imposed; otherwise, post auction trading willtend to undue the misallocation, and the anticipation of this tradingwill tend to control the auction pricing. The misallocation of goodsimposed by the seller through restrictions allow the seller to achievegreater revenues than if free resale were permitted. It is believed thatin an auction followed by perfect resale, that any mis-assignment of thegoods lowers the seller's revenues below the optimum and likewise, in anauction market followed by perfect resale, it is optimal for the sellerto allocate the goods to those with the highest value. Therefore, ifpost-auction trading is permitted, the seller will not benefit fromthese later gains, and the seller will obtain sub optimal revenues.

These studies, however, typically do not consider transaction costs andinternal inefficiencies of the resellers, as well as the possibility ofmultiple classes of purchasers, or even multiple channels ofdistribution, which may be subject to varying controls or restrictions,and thus in a real market, such theoretical optimal allocation isunlikely. In fact, in real markets the transaction costs involved intransfer of ownership are often critical in determining a method of saleand distribution of goods. For example, it is the efficiency of salethat motivates the auction in the first place. Yet, the auction processitself may consume a substantial margin, for example 1-15% of thetransaction value. To presume, even without externally imposedrestrictions on resale, that all of the efficiencies of the market maybe extracted by free reallocation, ignores that the motivation of thebuyer is a profitable transaction, and the buyer may have fixed andvariable costs on the order of magnitude of the margin. Thus, there aresubstantial opportunities for the seller to gain enhanced revenues bydefining rules of the auction, strategically allocating inventory amountand setting reserve pricing.

Therefore, perfect resale is but a fiction created in auction (game)theory. Given this deviation from the ideal presumptions, auction theorymay be interpreted to provide the seller with a motivation tomisallocate or withhold based on the deviation of practice from theory,likely based on the respective transaction costs, seller's utility ofthe goods, and other factors not considered by the simple analyses.

A number of proposals have been made for effecting auction systems usingthe Internet. These systems include consumer-to-consumer,business-to-consumer, and business-to-business types. Generally, theseauctions, of various types and implementations discussed further below,are conducted through Internet browsers using hypertext markup language(HTML) “web pages”, using HTTP. In some instances, such as BIDWATCH,discussed further below, an application with associated applets isprovided to define a user interface instead of HTML.

As stated above, the information packets from the transaction server toclient systems associated with respective bidders communicate variousinformation regarding the status of an interactive auction during theprogress thereof. The network traffic from the client systems to thetransaction server is often limited to the placement of bids; however,the amount of information required to be transmitted can vary greatly,and may involve a complex dialogue of communications to complete theauction offer. Typically, Internet based auction systems havescalability issues, wherein economies of scale are not completelyapparent, leading to implementation of relatively large transactionserver systems to handle peak loads. When the processing power of thetransaction server system is exceeded, entire system outages may occur,resulting in lost sales or diminished profits, and diminished goodwill.

In most Internet auction system implementations, there are a largequantity of simultaneous auctions, with each auction accepting tens orhundreds of bids over a timescale of hours to days. In systems where thetransaction volume exceeds these scales, for example in stock andcommodity exchanges, which can accommodate large numbers of transactionsper second involving the same issue, a private network, or even a localarea network, is employed, and the public Internet is not used as adirect communications system with the transaction server. Thus, whileinfrastructures are available to allow successful handling of massivetransaction per second volumes, these systems typically avoid directpublic Internet communications or use of some of its limitingtechnologies. The transaction processing limitations are often due tothe finite time required to handle, e.g., open, update, and close,database records.

In business-to-business auctions, buyers seek to ensure that thepopulation of ultimate consumers for the good or services are notpresent at the auction, in order to avoid the “winner's curse”, wherethe highest bidder in the auction cannot liquidate or work the asset ata profit. Thus, business-to-business auctions are distinct frombusiness-to-consumer auctions. In the former, the optimization by theseller must account for the desire or directive of the seller to avoiddirect retail distribution, and instead to rely on a distribution tierrepresented in the auction.

In the latter, the seller seeks maximum revenues and to exhaust thepossibilities for downstream trade in the goods or services. In fact,these types of auctions may be distinguished by various implementingrules, such as requiring sales tax resale certificates, minimum lot sizequantities, preregistration or qualification, support or associatedservices, or limitations on the title to the goods themselves. Theconduct of these auctions may also differ, in that consumer involvementtypically is permissive of mistake or indecision, while in a purebusiness environment professionalism and decisiveness are mandated.

In many instances, psychology plays an important role in the conduct ofthe auction. In a live auction, bidders can see each other, and judgethe tempo of the auction. In addition, multiple auctions are oftenconducted sequentially, so that each bidder can begin to understand theother bidder's patterns, including hesitation, bluffing, facial gesturesor mannerisms. Thus, bidders often prefer live auctions to remote orautomated auctions if the bidding is to be conducted strategically.

Airline Tickets

In the case of airline ticket distribution through the Internet, anumber of factors provide very real constraints on the auction process.For example, there are a number of sources for essentially identical (orstrictly higher valued) goods, typically with a fixed sale value. Inother words, tickets are available at a fixed price through thecomputerized reservation system (CRS) employed by travel agents, thusestablishing a maximum price, at which supply generally exceeds demand.Thus, the maximum selling price is typically well defined. Most routesalso have multiple carriers, providing external competition for theseller. It is also considered generally important that auctionparameters be maintained in general secrecy, especially before theauction, in order to prevent a competing seller from preempting sales byoffering a “better deal”. This may be accomplished by maintaining thestarting price, price increment and minimum price in confidence.

Airline ticket buyers are typically classified as business or leisure.The leisure traveler is characterized by the possibility of advancepurchase of tickets and willingness to purchase a round trip ticket witha Saturday night stopover. On the other hand, business travelerstypically travel on short lead times, and travel on weekdays, returningbefore the weekend. Leisure travelers are typically more price sensitivethan business travelers. Therefore, airline yield management systemsseek to maximize revenues by providing attractive fares to leisuretravelers more than two or three weeks prior to departure, andsubsequently raising fares in order to capture maximum profits frombusiness travelers. Fares are also set in response to so-called farewars between carriers, seasonal variations, and remaining inventory.Automated airline ticket yield management systems are typically employedto define these fares. In order to provide predictable alterations infares, a set of rules are defined for different classes of fares, suchas advance purchase requirements, Saturday night stopovers, holidayblackout periods, resale restrictions, and itinerary change fees. Theserules may be common throughout the industry, or customized.

There are typically two quite distinct motivations for conducting anauction of airline seats. First, in a business-to-business context, anauction provides a potentially efficient means for transferringinventory to so-called “aggregators” or “consolidators”, i.e., resellersof seats. These aggregators, in turn, may seek to fill their ownpredicted needs, or to define a tour group. In the former case, sincedemand is likely to be price sensitive, the total number of seats, aswell as their specific distribution through available flights, willdepend on the price point. In the later case, a relatively large blockof seats will be required, and the specific price per seat may be lessimportant than the economies of scale afforded by a large block. Theaggregators thus seek to efficiently procure inventory for theirpredicted needs, and must do so in an efficient, business-like manner,with little wasted time. Traditionally, aggregators negotiate price andvolume directly with airlines. Often, aggregators return inventory tothe airline if unsold, causing a variable number of unsold seats toreturn to inventory shortly before departure. Statistically, theairlines expect such returns, and reallocate these seats to later,higher fare travelers. Thus, prediction of the number of returns isimportant to assuring maximum profits.

It is also noted that the sales to aggregators are may be affected bymarketing schemes employed by various carriers, since these ultimatelycompete in the marketplace. There mere possibility of such variations inpricing of direct sales by airlines will impact the valuation placed onthe tickets by aggregators and the public. Since, the aggregators servea very real need of the carriers, that of low cost distribution ofinventory, and typically account for about 30% of ticket sales, thecarriers rely on this distribution channel and would prefer not toundermine it. Thus, a proper a priori model of supply and demand ispreferred to midstream corrections in pricing, such as by a sale or farewar.

The main distribution channels for airline tickets are theaforementioned aggregators, direct sales by the airlines, and theabove-mentioned computerized reservation system (CRS), such as SABRE,which serves the need of travel agents. These CRS systems provide anagency fee to the selling travel agent, as well as various rulesdefining payments to the carrier. Typically, tickets sold through a CRShave a published price for a class of ticket, and are sold on afirst-come, first served basis through authorized agents. In some cases,the CRS price is unpublished, and merely establishes a minimum price,such as tickets sold through Priceline.com. Once a ticket is soldthrough a CRS, the transaction is cleared through the airline hostcomputer to take the seat out of inventory.

At present, direct sales of airline tickets through the Internet bycarriers have emerged. In this case, typically the Internet web serverinterfaces with the airline mainframe, and thus these “direct” salescompete directly with the CRS system, at lower transactional cost to theairline due to the direct sales and elimination of agent commissions.Often, the sole use of these web sites make comparison-shopping lessconvenient, since each Internet web site typically caters to only asingle carrier. Typically, the sales price through the Internet are atthe same price as through the CRS, although various incentives, such asbonus frequent flyer miles, may be awarded for direct booking throughthe carrier's web site. Thus, for at least a portion of the sales, theInternet has proven efficient.

Traditionally, aggregators have directly negotiated with airlines fortickets. Therefore, the possibility of favoritism and inconsistency issignificant. There is no existing market mechanism for pricing oftickets to aggregators, yielding little present choice. Therefore, thereexists a present need for a system and method for establishing a marketprice for airline tickets to aggregators, for example by efficientauction. Since aggregators tend to be geographically dispersed,face-to-face auctions would be difficult to implement. One method ofalleviating the problems of remote auctions is through the use ofvideoconferencing technologies. This, however, is expensive and hassubstantial scalability issues.

Proxy bidding, including absentee proxy bidding, is well known in bothlive and automated auctions. Bidders, however, are typically constrainedto defining a maximum bid price, without other control parameters.

PRICELNE.COM, and Walker Digital, a related company, have developedsystems for the sale of airline tickets and travel accommodations, whichare especially suited for consumer transactions, and in fact, are inmany ways intended to exclude business transactions. For example,PRICELINE.COM runs a matching service for the sale of airline tickets.In one sense, since potential buyers place bids for tickets, the systemseeks to establish a market price; however, in implementation, biddersdo not compete with each other, except in a general way, and rathernegotiate with the airline, which often have rules regarding acceptablematch prices. The tickets sold through Priceline.com, in fact, aredistinguished from most normal tickets, in that they specify a departureand return date and city only, but do not allow specification of anairline carrier, flight number or time, or airport. Further, not onlyare these tickets non-refundable, but additionally the “bid” price isimmediately charged to a credit card as a part of the “bid” acceptanceprocess. The tickets of this special class are cleared through a CRS(Computerize Reservation System), and are assigned, by the airline thataccepts the “bid”, a specific flight. This system is apparently distinctfrom most auctions in that there is little attempt to efficientlyestablish a market price, since the process makes it difficult for the“bidder” to test the acceptance price point, and because the acceptedprice is not published. See, U.S. Pat. No. 5,897,620, Walker, et al.,issued Apr. 27, 1999, expressly incorporated herein by reference in itsentirety.

Strategic and operational planning for commercial airlines are highlycomplicated problems, especially since the industry has beenderegulated. In order to cope with this complexity, computer-baseddecision support systems have been adopted to facilitate the planning ofschedules, routes, aircraft and crew rotations and yield management.Airlines have thus developed Revenue Management Systems (RMS) (alsoknown as yield management systems) to optimize their revenue per flightRevenue management can be separated into two distinct parts: pricing andseat inventory control. Pricing involves the establishment of fareclasses and tariffs within those classes for each flight. Seat inventorycontrol is the periodic adjustment of available seats for the variousfare classes so as to optimize the passenger mix and thereby maximizethe generated revenue. In particular, the objective is to fly anaircraft as full as possible without allowing the earlier-booking(discount-fare) leisure passengers to displace the later-booking(full-fare) business passengers. Once a passenger books a ticket, theairline is required to place the passenger aboard the flight indicatedon the ticket rather than aboard a different flight for the sameitinerary, at risk of substantial penalty.

Revenue (or yield) management can be separated into two distinct parts:pricing and seat inventory control. Pricing involves the establishmentof fare classes and tariffs within those classes for each specificorigin-destination market. Seat inventory control is the periodicadjustment of nested booking limits for the various fare classes so asto optimize the passenger mix and thereby maximize the generatedrevenue. An airline's RMS typically knows well in advance, based onavailable historical data, that it will likely have empty seats on agiven route or flight, with more seats empty at certain times of the dayor days of the week. However, the RMS cannot simply discount thepublished fares for those seats without either starting a fare war orcompromising its underlying fare structure (i.e., without also having toreduce its full-fare prices for business travelers).

U.S. Pat. No. 5,270,921, Hornick, issued Dec. 14, 1993, expresslyincorporated herein by reference in its entirety, relates to virtualfare methods for a computerized airline seat inventory control system.An airline seat reservation system provides seat reservations controlledusing, in part, a computerized seat inventory control system, based onNetwork-Based Expected Marginal Seat Revenue (EMSR), incorporating aprobabilistic demand model without resorting to computationallyintractable integer programming. The seat inventory control system usesiterative leg-based methods to control bookings in a flight networkcomprised of a plurality of itinerary/fare class combinations using aplurality of flight legs. When considering a particular flight leg, thetotal fare paid by a passenger using the leg is adjusted by taking intoaccount an estimate of the displacement cost of the travel on the otherlegs of the itinerary to create a virtual fare. Expected marginal seatrevenues (or more precisely, their current approximations) provide thedisplacement costs on the legs when computing virtual fares. Using thesevirtual fares, a leg-based optimization method is applied to theindividual legs one-by-one to compute new approximations of the expectedmarginal seat revenues. This method is iterated until the expectedmarginal seat revenues converge to their network-optimal values. Thus,it is clear that optimization methods exist for pricing and segmentingclasses of airline seats; however, unsold seats remain, indicating thatthese methods are sub optimal. These methods, however, do provide usefulestimates that may be fine-tuned by other techniques or used as astarting point for further optimization.

Internet Auctions

On-line electronic auction systems which allow efficient sales ofproducts and services are well known, for example, EBAY.COM, ONSALE.COM,UBID.COM, and the like. Inverse auctions that allow efficient purchasesof product are also known, establishing a market price by competitionbetween sellers. The Internet holds the promise of further improvingefficiency of auctions by reducing transaction costs and freeing the“same time-same place” limitations of traditional auctions. This isespecially appropriate where the goods may be adequately described bytext or images, and thus a physical examination of the goods is notrequired prior to bidding.

In existing Internet systems, the technological focus has been inproviding an auction system that, over the course of hours to days,allow a large number of simultaneous auctions, between a large number ofbidders to occur. These systems must be scalable and have hightransaction throughput, while assuring database consistency and overallsystem reliability. Even so, certain users may selectively exploit knowntechnological limitations and artifacts of the auction system, includingnon-real time updating of bidding information, especially in the finalstages of an auction.

Because of existing bandwidth and technological hurdles, Internetauctions are quite different from live auctions with respect topsychological factors. Live auctions are often monitored closely bybidders, who strategically make bids, based not only on the “value” ofthe goods, but also on an assessment of the competition, timing,psychology, and progress of the auction. It is for this reason thatso-called proxy bidding, wherein the bidder creates a preprogrammed“strategy”, usually limited to a maximum price, are disfavored. Amaximum price proxy bidding system is somewhat inefficient, in thatother bidders may test the proxy, seeking to increase the bid price,without actually intending to purchase, or contrarily, after testing theproxy, a bidder might give up, even below a price he might have beenwilling to pay. Thus, the proxy imposes inefficiency in the system thateffectively increases the transaction cost.

In order to address a flurry of activity that often occurs at the end ofan auction, an auction may be held open until no further bids arecleared for a period of time, even if advertised to end at a certaintime. This is common to both live and automated auctions. However, thislack of determinism may upset coordinated schedules, thus impairingefficient business use of the auction system.

In order to facilitate management of bids and bidding, some of theInternet auction sites have provided non-Hypertext Markup Language(HTML) browser based software “applet” to track auctions. For example,ONSALE.COM has made available a Marimba Castanet® applet called Bidwatchto track auction progress for particular items or classes of items, andto facilitate bidding thereon. This system, however, lacks real-timeperformance under many circumstances, having a stated refresh period of10 seconds, with a long latency for confirmation of a bid, due toconstraints on software execution, quality of service in communicationsstreams, and bid confirmation dialogue. Thus, it is possible to lose abid even if an attempt was made prior to another bidder. The need toquickly enter the bid, at risk of being too late, makes the processpotentially error prone.

Proxy bidding, as discussed above, is a known technique for overcomingthe constraints of Internet communications and client processinglimitations, since it bypasses the client and telecommunications linksand may execute solely on the host system or local thereto. However,proxy bidding undermines some of the efficiencies gained by a livemarket.

U.S. Pat. No. 5,890,138 to (Godin, et al. (Mar. 30, 1999), expresslyincorporated herein by reference in its entirety, relates to an Internetauction system. The system implements a declining price auction process,removing a user from the auction process once an indication to purchasehas been received. See, Rockoff, T. E., Groves, M.; “Design of anInternet-based System for Remote Dutch Auctions”, Internet Research, v5, n 4, pp. 10-16, MCB University Press, Jan. 1, 1995.

A known computer site for auctioning a product on-line comprises atleast one web server computer designed for serving a host of computerbrowsers and providing the browsers with the capability to participatein various auctions, where each auction is of a single product, at aspecified time, with a specified number of the product available forsale. The web server cooperates with a separate database computer,separated from the web server computer by a firewall. The databasecomputer is accessible to the web computer server computer to allowselective retrieval of product information, which includes a productdescription, the quantity of the product to be auctioned, a start priceof the product, and an image of the product. The web server computerdisplays, updated during an auction, the current price of the product,the quantity of the product remaining available for purchase and themeasure of the time remaining in the auction. The current price isdecreased in a predetermined manner during the auction. Each user isprovided with an input instructing the system to purchase the product ata displayed current price, transmitting an identification and requiredfinancial authorization for the purchase of the product, which must beconfirmed within a predetermined time. In the known system, a certainfall-out rate in the actual purchase confirmation may be assumed, andtherefore some overselling allowed. Further, after a purchase isindicate, the user's screen is not updated, obscuring the ultimatelowest selling price from the user. However, if the user maintains asecond browser, he can continue to monitor the auction to determinewhether the product could have been purchased at a lower price, and ifso, fail to confirm the committed purchase and purchase the same goodsat a lower price while reserving the goods to avoid risk of loss. Thus,the system is flawed, and may fail to produce an efficient transactionor optimal price.

An Internet declining price auction system may provide the ability totrack the price demand curve, providing valuable marketing information.For example, in trying to determine the response at different prices,companies normally have to conduct market surveys. In contrast, with adeclining price auction, substantial information regarding price anddemand is immediately known. The relationship between participatingbidders and average purchasers can then be applied to provide aconventional price demand curve for the particular product.

U.S. Pat. No. 5,835,896, Fisher, et al., issued Nov. 10, 1998, expresslyincorporated herein by reference in its entirety, provides method andsystem for processing and transmitting electronic auction informationover the Internet, between a central transaction server system andremote bidder terminals. Those bids are recorded by the system and thebidders are updated with the current auction status information. Whenappropriate, the system closes the auction from further bidding andnotifies the winning bidders and losers as to the auction outcome. Thetransaction server posts information from a database describing a lotavailable for purchase, receives a plurality of bids, stored in a biddatabase, in response to the information, and automatically categorizesthe bids as successful or unsuccessful. Each bid is validated, and anelectronic mail message is sent informing the bidder of the bid status.This system employs HTTP, and thus does not automatically update remoteterminal screens, requiring the e-mail notification feature.

The auction rules may be flexible, for example including Dutch-typeauctions, for example by implementing a price markdown feature withscheduled price adjustments, and English-type (progressive) auctions,with price increases corresponding to successively higher bids. In theDutch type auction, the price markdown feature may be responsive tobidding activity over time, amount of bids received, and number of itemsbid for. Likewise, in the progressive auction, the award price may bedependent on the quantity desired, and typically implements a lowestsuccessful bid price rule. Bids that are below a preset maximum postedselling price are maintained in reserve by the system. If a certainsales volume is not achieved in a specified period of time, the price isreduced to liquidate demand above the price point, with the new pricebecoming the posted price. On the other hand, if a certain sales volumeis exceeded in a specified period of time, the system may automaticallyincrease the price. These automatic price changes allow the seller torespond quickly to market conditions while keeping the price of themerchandise as high as possible, to the seller's benefit. A “ProxyBidding” feature allows a bidder to place a bid for the maximum amountthey are willing to pay, keeping this value a secret, displaying onlythe amount necessary to win the item up to the amount of the currentlyhigh bids or proxy bids of other bidders. This feature allows bidders toparticipate in the electronic auction without revealing to the otherbidders the extent to which they are willing to increase their bids,while maintaining control of their maximum bid without closelymonitoring the bidding. The feature assures proxy bidders the lowestpossible price up to a specified maximum without requiring frequentinquiries as to the state of the bidding.

A “Floating Closing Time” feature may also be implemented whereby theauction for a particular item is automatically closed if no new bids arereceived within a predetermined time interval, assuming an increasingprice auction. Bidders thus have an incentive to place bidsexpeditiously, rather than waiting until near the anticipated close ofthe auction.

U.S. Pat. No. 5,905,975, Ausubel, issued May 18, 1999, expresslyincorporated herein by reference in its entirety, relates to computerimplemented methods and apparatus for auctions. The proposed systemprovides intelligent systems for the auctioneer and for the user. Theauctioneer's system contains information from a user system based on bidinformation entered by the user. With this information, the auctioneer'ssystem determines whether the auction can be concluded or not andappropriate messages are transmitted. At any point in the auction,bidders are provided the opportunity to submit not only their currentbids, but also to enter future bids, or bidding rules which may have theopportunity to become relevant at future times or prices, into theauction system's database. Participants may revise their executory bids,by entering updated bids. Thus, at one extreme, a bidder who wishes toeconomize on his time may choose to enter his entire set of biddingrules into the computerized system at the start of the auction,effectively treating this as a sealed-bid auction. At the oppositeextreme, a bidder who wishes to closely participate in the auction maychoose to constantly monitor the auction's progress and to submit all ofhis bids in real time. See also, U.S. patent application Ser. No.08/582,901 filed Jan. 4, 1996, which provides a method for auctioningmultiple, identical objects and close substitutes.

SUMMARY OF THE INVENTION

The present invention provides an efficient means for conductingelectronic commerce, and preferably market-based commerce, e.g., systemwhich test the supply and demand sensitivity of participants in order tocontrol price points or available inventory. Preferably,business-to-business and inter-commercial applications are segregatedfrom consumer transactions, both in user interface, rules and underlyingnature of the transaction.

In commercial circumstances, a delay of closing an auction for hours ordays is intolerable, as decisions or contingency plans must generally beestablished immediately. Further, inefficiencies due to server orcommunications latency and database inconsistencies in the conduct of anauction would impair confidence in the system, and potentially reduceoptimality. Thus, for commercial transactions, in order for an auctionto be considered efficient, it must have a duration commensurate withthe attention span of the participants, typically being opened andclosed quickly, with a high degree of activity throughout the progress,much as during a live auction. Bid entry and updates of client systemsare preferably instantaneous, requiring a “push” technology. Proxybidding should support advanced decision-making and strategies, ratherthan merely a simple maximum price.

The present invention therefore provides an automated auction systemwhich supports push technology for information updates, a large numberof simultaneous transactions, and rapid decision-making and auctionclosure.

Further, another aspect of the present invention provides a system forefficient communication between a plurality of client systems and acentral server, in which processing burden is essentially distributed tothe client systems, thereby facilitating server transaction processing.These communications may, but need not be, commercially motivated.

In a preferred embodiment, a system consisting of a server or serversand a plurality of internetworked remote client systems engage in adeclining price auction to liquidate quantities of perishable orreplenished inventory. The transaction server transmits, as necessary, acontext sensitive message defining an inventory status. Thus, in thecase of an airline ticket auction, the transaction server preferablyperiodically transmits updates of inventory remaining to each relevantclient system, for example a specific application program residingtherein. Where the update information is voluminous, the information ispreferably compressed to fit within a minimum number of packets. Eachapplication program interacts with a local server, which, in turn,employs standard protocols to interact with one or more user interfacesystems. A user interface system, through the local server, controls theapplication program to transmit, as appropriate, an efficient message tothe transaction server indicating a transaction or proposed transactionwith respect to the inventory. A process local to each client system,either embedded within the user interface system or application program,preferably implements a set of rules. This rules processor ensuresconsistency of the data within the transmission with presumptions orrules, or filters information from the client system, therebytransferring a processing burden from the transaction server (or host)to the client system.

In order to assure system integrity, data error correction and/ordetection, data encryption, and/or data (or rule) alteration detectionprocesses may be employed, either on the server or host alone or inconcert with the client system. The rule database on the client systemmay also be encrypted, or otherwise made tamper proof or tamper evident.Therefore, the information transmitted from the client system to thetransaction server may include various aspects. Preferably, theinformation is represented in the minimum number of Internet Protocol(IP) packets, i.e., one. However, not all information within the packetneed be compressed, nor need advanced features be implemented unlessnecessary.

It is noted that the communications system may be any accessiblenetwork; however, the public Internet is preferred for its open accessand standardized protocols. Likewise, a packet switched network, such asthe public Internet, is preferred over switched circuit networks fortheir ease of scalability. In order to overcome privacy and secrecyissues on the public Internet, a virtual private network (VPN) systemmay be implemented, in which network traffic is physically transmittedover unsecured channels, while logically a layer of encryption isapplied to ensure privacy of communications between cooperating systems.Typically, VPN's are implemented between servers or routers, which inthis case correspond to the central server and the local server.

In a preferred embodiment, a bid is represented in a single packettransmitted by the local server to the transaction server, including anidentification of the bidder, time of bidding, airline route or flightpair (for one-way or round trip passage, respectively), identificationof travelers (prime traveler and any companions), and consistency checkinformation. The transaction server, upon receiving the packet, decodesthe information and immediately seeks to confirm the bid, by checkingavailable inventory to determine whether the packet was received intime. If there is available inventory, the bid is confirmed and aconfirmation message, typically also a single packet, is sent from thetransaction server to the local server. Contemporaneously, theinformation in the packet is checked for self-consistency and forcompliance with rules. If the packet is found to have been tampered orotherwise inconsistent, the information may be forwarded to an automatedor manual exception handler. Typically, the bidder's credit ispreverified, and thus most credit information is already available andconfirmed. Upon bidding, the bidder's account is then charged for thebid amount, which is then verified to ensure that, for example, thecredit limit is not exceeded. This credit confirmation need not takeplace in real time, but since most credit information is preverified,the final verification may occur quickly, potentially allowing inventoryto be replaced in the auction in the event of a failure of verification,even during a short auction.

For example, in a declining price auction, the price progression may beuniquely defined by the starting price, price increment rate, priceincrement, ending price, starting time, ending time, or other relatedvariables, in the form of a set of rules. Therefore, a message may betransmitted by the client system, in accordance with the rules, whichdefine merely a time of bidding, which will specify the price inaccordance with the rules. However, armed with information specifyingthe algorithm or packet format, a user might surreptitiously alter theclock of the computer or the time-stamp of the packet. This, in turn,might otherwise result in an erroneous calculation of price, therebyreducing seller revenues.

A number of steps or precautions may be employed to prevent thisoccurrence. First, the client system, e.g. application program, may besynchronized with the transaction server (or a common external timereference) at a commencement of a communication session. Periodically,or even at random intervals, the systems may be resynchronized, withsignificant deviations reported as possible evidence of taintedtransactions or system failure. Further, outside of the real-timetransaction stream, the client system may communicate with the auctionsystem (to the transaction server or a different server within thecentral system), verifying packets which have been sent, e.g., byretransmitting the intended content in a secure, but not necessarilyreal-time communications session. The client system, e.g., applicationprogram, may employ data encryption or forward error correctiontechniques, for example with public key-private key technologies and/orwatermarks, to prevent or identify tampering with packet contents.

Since, in many instances, the conduct of the preferred auction is timedependent, it is important to synchronize the local server clock.However, this synchronization need not require network traffic with thetransaction server. For example, the local server may be designed toautomatically request time synchronization information from a trustedsource, such as the U.S. Naval Observatory or other time-sourceaccessible through the Internet. The local server may be updated asdesired or necessary to assure an accurate timebase.

This, of course, raises another significant advantage of the presentinvention. Because the rules are implemented remotely from the server orhost, the rules applied for each client system need not be identical,and indeed these rules need not be known or transmitted to the host.Rules, therefore, may define personal or private data. For example,certain users may be subjected to different discount rates, rebates,surcharges, quantity limitations, shipping/distribution issues, or thelike. In fact, the information displayed to a user interface in a clientsystem may be controlled by the rules. Another advantage of thisdistribution of intelligence is that the client system, may interactwith the user in a language of choice, using a desired screen format,etc. Thus, the client system may be subjected to various displayconstraints or optimizations, for example embodying a typical MicrosoftWindows 98/NT/2000 system, or a Windows CE personal digital assistant,or a wireless mobile device, e.g., employing wireless applicationprotocol (WAP) or the like.

In some cases, the IP packets intended for the local server would befiltered by a firewall arrangement. In this case, it is possible todesign the packets so that they appear to be standard HTML documentsdelivered through HTTP. This may require, for example, that the localapplet send a request packet, the response to which is the update. Inthis case, the request packet may be spoofed or directed to a differentdestination, to avoid network congestion on the operative transactionserver.

In other instances, the client system architecture is inappropriate forhosting the local server and application. In this case, the local serveror application may be physically remote from the user interface system.This may be the case, for example, with so-called net computers.Preferably, the local server is hosted separately from the transactionserver, again to avoid generating the kinds of network traffic from theuser interface that the local server is designed to prevent. Of course,collocation or integration of the local server and transaction servermay result in increased latencies for such user interface systems.

Since the auction need not be identical for each participant, it is alsopossible to distinguish classes of bidders by allocations of inventory.This allocation may be defined by the transaction server or by the localrules. Thus, a consumer bidder may be presented with a block ofinventory, while resellers are presented with a larger block ofinventory. Since the consumer bidders will see a declining amount ofavailable inventory, they will be forced to bid, if at all, prior toresellers. However, if the reseller requires a large quantity, or seeksto inflate the retail market price for the subject of the auction, hemay also participate in bidding on the earlier inventory. Theallocations need not be published, and in fact may be different forvarious tiers of reseller. Thus, multiple simultaneous private auctionsmay be conducted within the same schema, and potentially competing forthe same or overlapping inventory. Distinct pricing (e.g., discountrate, credit rules, surcharges, etc.), allocation, restrictions onresale, or other rules may be applied to protect a distribution channel.

The rules may also be adaptive, either based on interactions with theuser, based on the context of use, or both. See, U.S. Pat. Nos.5,920,477; 5,903,454; 5,901,246; 5,875,108; 5,867,386; and 5,774,357,expressly incorporated herein by reference.

In the event of adaptive rules, it is preferred that critical rulescommon to a plurality of bidders be adaptive to the same elements. Thus,the rules cached locally include a common set of adaptive factors, sothat the normal communications from the transaction server adapt theclient systems, and the transaction server (or other logical elementassociated with the central system) can predict the particular state ofthe local rules for each client system, thereby allowing an interpretinga transaction packet from the client system, in the event that thepacket cannot be interpreted without reference to this information. Therule pattern, as discussed above, may be uniform (and therefore a prioriknown to the host) or private and secret. However, it is also possibleto also provide an identification code for each rule, and transmit thecode from the client system to the transaction server with transactioninformation. In similar form, the client system may encompass a largeset of rules, some of which are applied to any given transaction. Theserules may be applied in context sensitive manner, i.e., based on theapplicability of the rule to the situation, either determined implicitlyby the client system or by explicit control or selection by the user.The particular rules applied may then be identified to the transactionserver.

A preferred adaptive progression scheme provides that, as buyers takeinventory, the amount of the price reduction becomes smaller. Theauction duration and price decrement interval remain constant.

The rules need not relate to essentials of the conduct of the auction,but may also relate to ancillary issues, such as ticket deliveryoptions. Thus, where there is sufficient time between the auction anddeparture, mail delivery may be acceptable. On the other hand, withinsufficient lead-time, overnight delivery may be the only option. Suchrules may be readily implemented in the local server, thereby minimizingnetwork traffic between the local server and transaction server, andpotentially allowing customization of rules, such as hand pickup ormessenger where such is appropriate, without making such optionsgenerally available.

Another example of a rule, which may differ between respective bidders,involves frequent flyer miles. Thus, for example, a carrier may define arelationship between frequent flyer miles and cash bids, storing abalance on the client system local database, e.g., within a databaseassociated with the application program. The bidder may then bid thesefrequent flyer miles for passage. The carrier may, for example, applydifferent valuations for different routes, or apply differentrestrictions for frequent flyer purchases than for cash (or credit)purchases. Hybrid purchases and upgrades may also be permitted.Differing priorities may also be associated with various bids; forexample, a confirmation message may be delayed to any client systemuntil a set of bids is received. Bids sharing common parameters orwithin a common time window are then sorted, with the highestprioritized bids being confirmed and the remainder being non-confirmed.Thus, for example, a rule may be implemented at the transaction serverto prevent frequent flyer mile-funded purchases from displacing cashpurchases, all other parameters being equal; on the other hand, customerloyalty may also be rewarded by prioritization within the system.

Thus, it is seen that a number of options are available for managing theintelligence and rules at the client systems, without imposing a largecommunications burden.

In a preferred embodiment, the architecture encompasses both the client(e.g., client system) and server (e.g., transaction server), asdiscussed above, and a separate user interface presentation systemassociated with the client. The user interface may reside within thesame processor complex as the client, or be physically separated.Typically, this separation is by way of a high bandwidth link, such as alocal area network. The user interface may be, for example, an applet orHTML/XML document viewed by an appropriate browser, with or without aplug-in application. It is also possible to employ elements ofSynchronized Multimedia Integration Language (SMIL) (BostonSpecification, W3C Working Drat 3 Aug. 1999,http://www.w3.org/1999/08/WD-smil-boston-19990803/); See alsohttp://www.w3.org/TR/smil-boston, which may evolve as standardextensions to browser functionality, to handle certain real-time-relatedtasks. The client system preferably communicates with the transactionserver using the Internet (IP) protocol, although not employinghypertext markup language (HTML) protocol or extensible markup language(XML) protocol, in order to provide efficient machine-to-machinecommunications. Preferably, the client system is organized to have anapplication program executing which controls this aspect of thecommunications, and which may implement a virtual private network-typesystem, The application program is preferably linked to the local serverthrough a set of application programming interfaces (APIs), to allow arelatively tight coupling. On the other hand, the client systempreferably employs a standard protocol for communicating between thelocal server and the user interface system component, for example usingIP sockets, and therefore allows communications through TCP/IP protocol,and use of a standard browser or Internet applications. It is noted thatcommunications between the user interface system and local server neednot be compressed or highly efficient. The application program of theclient system typically implements the rules, especially where astandard browser is employed to provide the user interface. Alternately,the rules may be implemented in an applet or browser plug-inapplication. For example, a JAVA applet may be provided on a user'smachine to generate and display the user interface, e.g., employing aJAVA virtual machine (JVM).

In the case of an airline ticket system, a database is maintained ofticket and route information, as well as a set of rules, such asavailable round-trip pairs, stopover requirements, and temporalparameters relating pricing changes. Preferably, the ticket and routeinformation database is implemented in the local server system, althoughit is also possible to implement this in either the applet or a remoteserver. In the case of a remote server, it is preferred that the serverbe distinct from the transaction-processing server, in order to reduceload on the transaction server.

In a preferred embodiment, a user, through a loader application, invokesa local server application, which then initiates a communicationssession with a remote system. In an initial communication, the localserver communicates with the central server system to determine whetherit requires updating. If it does not include the most updatedinformation required, it is updated, including program code, applets,and database information, as necessary. The clock of the local server isalso synchronized prior to an auction. Thereafter, an HTML page opens ina standard browser, typically buffered locally. The user then interactswith the HTML page, which may further reference local or remoteresources in standard manner. When the user seeks to invoke an auctionor other applet based system, a universal resource locator (URL) directsthe user machine to load and invoke an applet. This applet thencommunicates directly through an IP stack in the user's machine with thelocal server, which then engages in a “dialog”, in which the userinterface applet receives necessary information from the local serverfor display.

A degree of intelligence, represented by a set of rules, is implementedin the local server, which, based on previously stored information andselected choices by the user, ensures that subsequent selections ofoptions and choices by the user are consistent with prior selections andchoices, and all abide by the set of rules. For example, if a priorairline reservation encompasses a block of time between departure andreturn, no additional tickets can be purchased within this time-period.Of course, further intelligence may be applied, for example looking atthe presumed location of the traveler to allow a complex itinerary whilepreventing inconsistent travel reservations.

When the user is ready to complete a transaction, for example byaccepting the then-displayed price for an available quantity of tickets,only then is communication required to transmit a packet from the localserver to the transaction server. The local server communicates aminimum amount of information to the transaction server, including theidentity of the bidder, route(s) being bid on, the bid parameters, e.g.,time of bid in a descending price auction, and possibly otherinformation and error detection codes. Typically, the transaction serverimmediately responds with a confirmation of the proposed transaction,which may be accepted or denied, for example if no remaining inventoryremains or the packet including proposed transaction information fails aconsistency check to ensue integrity. If confirmed, the transaction iscompleted at the transaction server, and the confirmation logged on thelocal server, forming a part of the database of past selections andchoices for the application of rules. If not confirmed, the proposedtransaction may be nulled, or otherwise processed by the local server.For example, an alternate itinerary may be presented for bidding.

In the case of an end-traveler auction, the transaction processingtypically includes charging a credit card for the tickets. If the creditcard transaction fails, the transaction may be “unconfirmed”, thusreturning the tickets to the airline inventory. Preferably, the“unconfirmation” process updates the local server to allow the user tolater participate in auctions that would have been blocked by theconfirmation. Alternately, the custom rules for each client system areuploaded each time the system is resynchronized. This technique,therefore allows the user to maintain consistency while employingmultiple terminals. e.g., home, office, etc.

According to another embodiment of the invention, a system for airlineticket aggregator use is provided. In this case, consistency rules andother end-user specific rules are not applied in the same way. Further,in contrast to end-traveler auctions, tickets are generally sold forone-way passage, rather than round trip, allowing the aggregator to pairtrips. In the case of aggregators, however, the system may implementrules relating to, for example, available credit limit. Thus, anaggregator may only be permitted $100,000.00 of outstanding tickets atany time. The local server therefore accumulates total dollar volume oftickets sold, warning the aggregator as he approaches the limit. In theevent of aggregator firms, the local server feeds data to a plurality ofclient machines, allowing consistency across a plurality of users.

In the event of proxy bids, the rules implemented on the proxy systemare preferably synchronized with the local server, either during theauction, if the local server is on-line, or during next sign-on, if thelocal server is unavailable.

In establishing a declining price auction for airline tickets, theauction starting price may be, for example, the published price for acomparable ticket. Based on a synchronized clock, the price declinesover time. In a preferred embodiment, the price declines by linearincrements, over a fixed period of time, to a predetermined minimumprice. Each prospective buyer submits a bid at the value assigned bythat buyer, as the price reaches the desired level. A buyer may assign avalue to the tickets based on remaining inventory, seeking to submit abid as the inventory declines to the minimum number of tickets required.The buyer may also base his strategy on the nature of the goods, price,and bidding tempo. Of course, if each buyer seeks to wait until the lastpossible moment, then the bids will all be clustered, increasing therisk of waiting. Alternately, a proxy bidder is programmed, preferablyincluding a price vs. remaining quantity function, with an increasingstrike price as remaining quantity is lowered. The auction runs for apredetermined period, e.g., four minutes.

The remaining available quantity may be hidden or visible to the bidder.If it is visible, it may be represented numerically or graphically, suchas with a bar graph. If not visible, the bidder is informed, forexample, only that inventory remains. In this later case, the clientsystem need only be updated for inventory status when non remains. Wherethe auction seeks to sell a matched pair of airline tickets, forexample, a bar graph may be employed to show remaining quantity of bothdeparture and return flights. Thus, the bidder may be afforded theoption to alter one leg of the trip where there is a disparity inremaining quantity. Thus, if inventory of seats for one leg of a trip isexhausted, the bidder may seek an alternate flight, rather than beforced to bid for the scarce resource and the abundant resourcetogether.

Buyers with a large demand may test the market by buying smallquantities of inventory as the price declines, since this will havelittle effect on the average inventory cost. Buyers with low risktolerance (i.e., the risk of coming away from the auction withinsufficient inventory for its own business needs) will also bid early.When the quantity remaining equals the quantity desired by a bidder,that bidder would normally seek to acquire the remaining inventory. Infact, since competing bidders presumably desire multi-unit blocks, itwould be a high-risk strategy to wait until the minimum quantity desiredremains, since the quantity could quickly increment below the minimumsize block desired. Further, in this setting, bidders with an appetitefor large blocks would tend to bid higher than those with a demand for alower quantity. This aspect of the declining price auction is somewhatdifferent from an ascending price auction, in which those with a demandfor lower quantities tend to preferentially win with respect to thosewith similar private values but demand for larger quantities.

In a business-to-consumer auction, the buyer is the traveler, with nointent to resell. In this case, the auction is intended, not so much toestablish a market price and move large quantities of inventory, butrather to efficiently fill seats (at the highest possible price) thatmight otherwise remain unsold. In this case, typically, individualconsumers will have a demand for a relatively few seats. Thus, suchconsumers will be unlikely to test the auction, as any “early” bid willclearly increase the costs. The highest price corresponding to thebidder's maximum utility will therefore be suppressed. On the otherhand, when the price reaches what a group of bidders perceives as theappropriate price, an avalanche effect will occur, with a potentiallyrapid clearance of the market close to that price, resulting in anefficient auction result.

The present invention provides a feature that allows a user to programin a demand curve before the auction, which may be potentiallyoverridden by the bidder during the auction. The mere existence ofpreprogrammed or proxy bidders forces even the live bidders to plan andanalyze their private value and demand curve prior to the auction. This,in turn, will generally promote higher initial bid prices, since apreprogrammed proxy bidder will not hesitate.

According to a preferred embodiment, airline tickets are auctionedduring a series of relatively short auctions with scheduled duration.This allows participants to monitor an auction continuously frombeginning to end, and to strategically place bids to optimize the pricepaid and the risk of losing the bid.

The display interface of the user system is preferably updated in realtime, with very short latency between the entry of a bid by one bidderand updating of screens of all other bidders. Bids are also entered inreal time, meaning that there is no substantial latency between thevolitional act by a bidder in placing the bid and the transmission of apacket to the server. This is due, in part, to the implementation ofrules as soon as applicable, avoiding ancillary decision-making at thetime of entry of the bid. Further, since a race condition, i.e.,competing inconsistent conditions, is possible, verification also comesimmediately to the bidder by return packet.

Typically, a number of auctions are conducted simultaneously. In thiscase, the packets from the transaction server include update informationfor all auctions selected as being monitored by the client systems, thenin progress, in a compressed format, further increasing efficiency.These aggregate packets are received by the local server and passed tothe applets associated with user interface system(s) for display, basedon the particular auction being monitors.

In order to assure scalability, a preferred embodiment of the inventionemploys a multiprocessing hardware implementation, for example anInternet server comprising six Pentium III Xeon dual-processor systemsinterconnected with a 100 Base T network, with a separate databaseserver, e.g., an IBM RS-6000 server, with a redundant array ofinexpensive disks (RAID) storing the data. One of the processor nodescoordinates the auction, while the remaining nodes are symmetric and arebalanced handle the auction process. Thus, each IP packet from a bidderis received by one of the Internet server processor nodes, and isprocessed. Likewise, the Internet server updates each bidder withauction information in real time. Upon closing of a transaction, e.g.,purchase of an airline ticket, the database server opens (or creates) anappropriate database record, and updates the relevant portions of thedatabase. The bidder account is then charged, for example through acredit card. Upon clearance of the transaction, the airline hostcomputer is updated with the indication of the ticket sale. Generally,the airline inventory subject to auction is reserved in the auctionsystem, and is thus not available for sale through other channels forthe duration of the auction, which is generally a few minutes. It isalso possible, however, to update the auction process from the airlinehost system, at the penalty of potentially increased latencies.

The local server may serve a number of different user interface systemsand users. Therefore, the path between the transaction server and localserver is akin to a virtual private network bridge, which efficientlytransports packets between sub-networks. Using this architecture, theclient system is not limited to a particular platform. Thus, assumingthat the client system applet is written in JAVA, any system thatsupports JAVA applets may be used as the client hardware.

Therefore, by providing an efficient proprietary packet format, ratherthan the relatively inefficient HTML protocol designed primarily topresent human readable text pages through a standard browser, nearreal-time performance can essentially be maintained even in the absenceof guaranteed Internet “quality of service”. This is principally becausethe data is compressed into a minimum number of packets, and because theserver need only broadcast a small number of packets, e.g., one perlocal server, while servicing a large number of client systems. Inprincipal, a number of intermediates or proxy servers may be interposedbetween the transaction server and client systems, potentiallyoffloading certain processes from the primary transaction server whileonly slightly increasing the minimum packet delivery latency andreducing the average packet delivery latency.

Architecturally, the system therefore consists of a transaction server,which manages inventory and bidding, which cooperates with an internalor external proxy bidding application. For example, the proxy biddingapplication may be situated as a set of virtual clients within a localarea network including the transaction server, producing bids atappropriate times. The transaction server is tightly integrated with anInternet server, which implements a virtual private network, linking toa plurality of client systems. Each client system communicates withauthorized bidders at user interface systems thereof. The client systemtypically incorporates a user interface system, which may be astandard-type browser with support for JAVA applets, a local server,communicating with the user interface system and applets, and anapplication program, coupled to the local server using a set ofapplication programming interfaces (APIs) to provide local intelligence.The local server supports standard IP socket protocols, and may supporta large number of user interface systems on the same local network. Theapplication program communicates with the transaction server employingIP communications as well. The application program may directlycommunicate with the transaction server, or communicate through thelocal server.

It is noted that, in many instances, the user interface system, thelocal server and the application program will all reside on a singlepersonal computer. In this case, the personal computer operating systememploys a single TCP/IP stack. Thus, the user interface communicateswith the local server through the TCP/IP stack, and the personalcomputer conducts all Internet communications through a single TCP/IPstack, e.g., WINSOCK.DLL. The application program therefore may be anapplet that communicates exclusively through the local server orpotentially directly with the TCP/IP stack.

According to a preferred embodiment of the invention, the traditionalDutch auction format (declining price auction with linearly decrementingprice and lowest successful bid pricing) is modified somewhat, for thesale of, for example, airline seat inventory. Each auction is preferablytimed, to provide a predefined schedule, although an adaptiveprogression scheme could be implemented based on bidder activity levelsor the like. In this case, a clock starts the auction, and the lot upfor auction would consist of a block of airline seats, for example 20 to50 seats. As time elapses, the offering price drops at regularintervals, e.g., about $10 every 15 seconds. Again, the price drops mayoccur according to other formulas, such as an exponential decline, or byan adaptive scheme based on remaining inventory, bidder activity, andtime remaining (if a fixed period auction). In fact, according to anadaptive scheme, pricing can actually increase based on high demandconditions, in a generally decreasing price auction.

It is also noted that the auction system may withdraw availableinventory automatically as the price declines, or add inventory to meetdemand at an advantageous price. Thus, the auctions rules may be quitesophisticated, based on local adaptive algorithms and sparse datatransmitted from the central transaction server.

In the auction, a bidder can opt to buy a preset number of seats at aprice that is acceptable to him. As the price changes, additionalbidders can purchase the remaining inventory as long as there isinventory left or until the clock reaches zero, ending the auction.Preferably, auctions maintain their starting and ending times, in orderto maintain a schedule; however, even this constraint is subject torelaxation.

Each successful bidder receives the requested number of seats, at theprice being offered when he elected to buy, Alternately, the price maybe based on the lowest successful bid price, although this may producelower profits for the auction. Such a strategy may be modified byallowing the supplier to withdraw remaining inventory at any time,ending the auction.

In a practical example without adaptive features, an airline seeks tosell tickets on a certain route. If the opening price is $500.00, andthe lowest acceptable price is $200.00, the difference is $300.00. Ifthe total auction time were set for 4 minutes and updated every 20seconds, there would be 12 equal increments. In that case, the pricewould drop 300/12 or $25.00 every 20 seconds. If the update rate is setto 15 seconds, there would be 16 equal increments and the price wouldthen drop by $18.75 every 15 seconds.

All three variables—opening price, lowest acceptable price and updaterate are independently adjustable, providing for an optimum linearlydeclining price rate. Also, with this concept it is possible to runsimultaneous auctions of distinct inventory with differing opening andlowest acceptable prices; of course, resulting in varying decliningprices. The length of the auction and the update rate are the only twoelements that would remain constant. This simplifies interprocesscommunication, but is not a necessary feature of the system according tothe present invention.

Preferably, the auction schedule is predetermined, allowing a user todetermine within a short period whether he or she will be the successfulbidder. Thus, for example, auctions run for a period of four minuteswith a one-minute pause in between auctions. This allows for 12 auctionsper hour on a preset schedule. The entire set of auctions may beperiodically repeated, for example daily or consecutively, withremaining inventory from prior auctions and/or with replenishedinventory released over time. The order of the auctions may be set tomaximize profits, such as by predicting parasitic demand factors andordering to achieve highest auction pricing, based on a previouslyobtained knowledge base. In fact, it is believed that convenience in thepurchasing process may be a substantial factor, and therefore a buyermight be willing to pay relatively higher prices for tickets (ascompared with other deep discount alternatives) so long as they areavailable and closure of the transaction assured within a short period.

Airline auctions according to the present invention preferably providesimultaneous auction of all gateway cities (city of original departure),organized by city-pairs. An auction consists of all flights originatingfrom a particular gateway city-pair covering a date range of one week.For example, a gateway city-pair is New York (JFK) to London Heathrow(LHR). The date range is, for example, February 20-26. This auctionorganization is premised on the use of the auction by or forindividuals, since an individual is unlikely to be making flightsoutside a city pair more than once a week, it is unlikely that thatperson would need to be involved in more than one auctionsimultaneously. In the event that this is not the case, the bidder mayemploy proxy bidding or simultaneously monitor and bid on a plurality ofauctions.

This organization may also be useful for aggregators, those who seek topurchase blocks of airline seats for resale to others, and who can bidbased on anticipated needs for any week and city pair.

In one type of system, where it is presumed that all demand will not beliquidated during a single auction, each date range from a particularcity-pair may be repeated once per hour until its inventory isexhausted. Given this organization, if no inventory has been allocatedby the airline for a specific gateway, flight or departure date, noselections will appear in the auction screen.

In like manner, multiple airlines may provide inventory within the sameauction. Therefore, the bidder may have not only the choice of gatewaycity, date and flight, but also carrier.

In fact, while a multi-carrier auction would on one hand providecompetition within a single auction for sales, it would also providegreat incentive for all representative bidders to participate in theauction. Therefore, a single channel would be established withoutparasitic competition for the system. This, in turn, would more reliablyestablish a market price, and therefore reduce the bidder's and seller'srisk that the auction market is not representative. This reduction inrisk equates to greater efficiency, and may yield greater optimality. Inorder to implement a multi-carrier auction, the respective products orservices from the various sellers must be commoditized. Thiscommoditization may be by the sellers or auctioneer, who in this caserepresents multiple competitors, or through a pre-auction analysis byeach bidder. For example, a bidder may apply rules to slightly differentvalued inventory, such as a discount rate, to allow them to be groupedtogether without distinction. The auctioneer, however, must assure thatcomparable inventory is auctioned simultaneously. Once the goods arecommoditized, and grouped together, at least at the user level, theauction commences. The bidder places a bid, which is then translated,through the rules applied at the client system or the transactionserver, into a particular bid for particular goods. Since, in apreferred embodiment, a declining price auction is implemented, a bid isessentially an irrevocable offer to purchase, which must be immediatelyconfirmed by the auction system. In this case, the auction system, inconjunction with the client system, resolve any ambiguity in the bid,and provide confirmation to the bidder. In some cases, the auctionsystem may apply higher order intelligence to matching the bid price tothe goods being auctioned. In this case, after resolution of ambiguity,the bidder may be permitted to reconfirm the specific transaction.

Upon confirmation (or reconfirmation), the transaction server thenimmediately communicates with the respective seller, typically by adedicated communications channel. In the event of airline tickets,typically a leased line arrangement is implemented, although virtualprivate networks, frame relay, dial-up integrated services digitalnetwork (ISDN), digital subscriber line (DSL), or the like may also beused. Standard Internet communications are disfavored because of thepotential for delay or lost packets. In the event that a confirmation isnot available from the initial intended supplier, if the implementingrules permit, the transaction server may attempt to confirm for anequivalent alternative. If all sources fail to confirm, the bidder doesnot receive confirmation, and may further participate in the auction forother inventory. If the bid is confirmed, the auction rules may requirethat the bidder be removed from the auction, or that furtherrestrictions be placed on inconsistent bids. In any case, the bidder ispreferably informed by return information packet that the bid wassuccessful or unsuccessful. In contrast to typical auction systems, themulticarrier auction system described herein resolves one carrier from aplurality, and communicates transaction information therewith.

In order to provide a fair forum for all carriers, the inventory may beliquidated in random or round robin fashion. Further, the airlines mayin essence conduct a reverse auction to prioritize the liquidation ofinventory. Some airlines would seek to reduce risk of unfilled seats,and therefore risk low pricing. Other airlines would seek to maximizepricing and therefore risk unsold inventory. It is therefore evidentthat a simple declining price auction would be ineffective, since thisprocess requires liquidation of higher priced inventory before lowerpriced inventory. It is apparent that, if carriers place differenteconomic parameters on respective inventory, these may not becommoditized together by the auctioneer, and that, since some buyersaccept the higher price inventory over known lower priced inventory,that bidders distinguish the value of this inventory. This process maybe addressed by allowing the bidder to apply an equalization function tovalue the respective inventory together. Thus, services of a majorcarrier may be considered worth 25% more than services of a limitedcarrier. Once this valuation is applied as a rule, two simultaneousauctions for the respective carriers may be merged, on the bidder's userinterface, into a consolidated equalized auction. The bidder may beaware or unaware of the carrier whose inventory is being bid on, andthus the actual price being bid. At each time point, therefore,inventory of multiple carriers may be represented, if within thecalculated pricing parameters. While carriers may a priori determineauction parameters, placement in the auction may also be determined in acompetitive process. In this case, carriers disclose proposed pricingschemes, and seek, through competitive processes, to best conform thepricing to their respective economic models. In order to avoid antitrustconsiderations of direct collusion in pricing, the communications may bemade through an impartial forum, such as the auctioneer.

The present system may also be used to provide other services totravelers. For example, the registration and bidding by a travelerprovides substantial and valuable information to the auctioneer. Even ifthe bidder is unsuccessful, he may be offered ancillary services for thecorresponding trip, including hotel, car rental, concierge services,show and event tickets, etc. Targeted banner ads may also be directed tothe user, especially in non-time sensitive communications periods. Thelocal server may also present advertising information to the user from alocal cache, thus reducing telecommunications system load whiledirecting relevant information to the user. These ads may be presentedthrough the user interface applet or the browser system. Thus, adatabase may be maintained of travel plans, for uses outside of theauction process itself.

The auction system need not be limited to airline tickets. For example,commodities, such as oil and gas, are routinely auctioned. The presentsystem also allows services and intangible rights to be auctioned. Thus,for example, telecommunications carriers may auction short-termcapacity, or guaranteed quality of service commitments, based onprojected available short-term capacity. This allows such commodities orservices to be sold at a market price, without requiring a prediction bythe seller of an appropriate fixed price to maximize profits. Further,once a bidder chooses to participate, it is likely that he will bid,unless quantity is extinguished prior to reaching his utility price;thus, there is likely to be fewer “window shoppers”.

The local server/transaction server architecture according to thepresent invention need not be dedicated to any specific type ofinventory to be liquidated, and thus may be provided as a service tovarious sellers of various products or services. As stated above, thesystem need not be limited to a single vendor, and may thus encompass aglobal market. Further, in an adaptive scheme, a continuous auction maybe implemented, continuously setting a market price and liquidatinginventory at that price, rather than in a fixed price auction. Ofcourse, a continuous auction generally requires a very large orregenerating inventory and sufficient trade volume to ensure true marketvaluation. Thus, telecommunications services are a good example of a“commodity” which may be continuously auctioned.

In addition, the transactions processed need not represent auctionpurchases. For example, inverse auctions, or offers for sale, may becommunicated and resolved through the present system. A market systemmay also be implemented within a corporate Intranet, to redeploycorporate resources. In this case, cooperative bidders may use theprocess to allocate resources to the most highly valued user. Often, acommon currency is required, such as budget dollars, but a barter systemmay also be implemented. Likewise, a human decision-maker may alsodetermine the value of a bid or available “credit” for a bidder, inorder to confirm a bid.

In some instances, it is considered important to shield priceinformation from casual observers, and to shield bid prices betweencompetitors. In an Internet auction, bids and proxy bids may bemaintained in confidence. Further, a registration process may beemployed to prevent casual review. Finally, by employing an applet-baseduser interface with a proprietary data format, it would be difficult fora bidder to download or print the history of an auction, for futureanalysis. In fact, according to the present invention, the auctionsystem has the ability to alter the fundamentals of the auction duringits conduct, for example by lowering or raising prices, increasing orwithdrawing inventory, or altering the time course. These alterations(or even their potential) may impose noise on the bid informationreceived by any one bidder such that analysis of the presented datawould be futile.

BRIEF DESCRIPTION OF THE DRAWINGS

The preferred embodiments will now be described with reference to thedrawings, in which the same features of the drawing is represented withthe same reference numerals:

FIG. 1 shows a sign-on display screen;

FIG. 2 shows an auction schedule bulletin board;

FIG. 3 shows an auction route selection screen;

FIG. 4 shows an auction bidding screen;

FIG. 5 shows an upcoming auction status screen;

FIG. 6 shows a proxy bidding screen;

FIG. 7 shows a purchase confirmation screen;

FIG. 8 shows a block diagram of a system architecture; and

FIG. 9 details an adaptive algorithm according to the present inventionfor determining an auction price, based on starting price, ending price,time and time increment, seats originally available, and seats sold.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

According to a preferred embodiment, an airline ticket declining priceauction is implemented. The system preferably allows multiple bidders tocommunicate with an auction system through the Internet and providereal-time bidding and responses.

According to the present invention, to participate in an auction, theprospective bidder must obtain the application and local serversoftware, for example, by downloading the application from an FTP server114, a “loader” disk or CD-ROM. Access to this application may berestricted, and thus the system may be private or exclusive, or publiclyaccessible. Typically, the bidder will execute the loader programprovided to him on a CI)-ROM, which launches the bidder's internetbrowser and then automatically downloads or copies the application tothe bidder's local machine or client system 100. This architectureenables all the graphic images or HTML pages to be stored locally andnot have to be downloaded each time the bidder accesses the auctionapplication. The flight schedule is stored locally in a database. Oncelaunched, the application software program 104 will thus automaticallydownload any updated auction files, e.g., program updates, flightschedule database updates, rule updates, bidder record updates, etc.,from a remote auction system server 110, ensure that the bidder isproperly registered, and allow a registered and qualified bidder to joinin the auction process. Upon initial use, a database file 106 is updatedon the client system 100 with identifying information.

The registration form includes the bidders credit card information,including billing address, telephone numbers and email address. Thisform also provides for a default list of travel companions 12. Forexample, family members or business associates. Once completed, thisinformation is then submitted to the auction system 110 for validationof the credit card data through the credit card verification system 117.An auction activation key is, for example, sent to the bidder via hispreviously provided email address, for entry as an initial password 3.

In the preferred embodiment, after the application has been downloaded,it creates a desktop icon under Windows a 95/98/NT/2000 system, which isdisplayed on the bidder's computer desktop. To launch the set of auctionsystem applications, the bidder may simply double-click on the auctionicon, which launches the local server 101 and application softwareprogram 104, which in turn opens an HTML page, causing the operatingsystem to launch the default Internet browser 102. If necessary, adial-up connection to the Internet 105 is also initiated.

The bidder is thus initially presented with a login screen 2, as shownin FIG. 1. The login screen 2 requests a user password 3, without whichaccess is denied. The auction application is accessed through anInternet browser, which displays an HTML screen 1.

Once logged in, a bidder may participate in an auction in several ways:in a single auction (one city-pair); in multiple auctions (more than onecity-pair); and via a proxy bidder 113.

To accommodate as many bidders as possible, the amount of datainterchange between client system 100 and auction system 110 ispreferably held to a minimum, especially while an auction is inprogress. The local server 101 typically acts as a “server” only to thebrowser application 102, by accepting connections from the browser 102and providing HTML documents. The browser 102 requests can also triggerthe application software 104 to perform dialogs through application orapplet screens with the user, unrelated to the browser 102, for examplethe log-in screen 2. The application software 104 also acts as a“client”, making connections through the Internet 105 to the remote HTTPserver 119 and other resources through the remote socket server 112,when necessary, for purposes of providing and receiving updatedinformation, such as, current inventory status, and synchronization ofthe auction clock 20. In an alternate embodiment, the local server 101and local application software 104 may reside on a computer physicallyseparate from the client system 100, and, for example, communicate withmultiple browsers 102 through a local area network, Although significantbandwidth is required at the transaction server 111 for handling thebidding through potentially hundreds or thousands of client systems 100,the required bandwidth is not as intensive as would be required forcontinuously updating prospective buyers with seat inventory status anddirectly communicating with Internet browsers.

The information that resides in the database 106 on the client system100 prior to the auction is typically pseudo-static information, suchas, flights being offered for auction (flight number and date), openingprice, and lowest acceptable price. These variables are located intables, from which all other parameters are calculated. These parametersinclude, but are not limited to, auction number, declining priceintervals, and departing city. Thus, the information required to betransmitted from the transaction server 111 during an auction isminimized.

When an auction starts, the local server 101 associated with the clientsystem 100 requests a socket session from the socket server 112, whichmay, for example be limited to processing transactions for a particulardeparture city that bidder wants to bid on. That particular actionensures that the application software 104 program version on the clientsystem 100 is the most current (and if not downloads an update),synchronizes the auction clock 20 on the client system 100, anddownloads the seat inventory 43 for his desired selections. This socketsession of the socket server 112 remains open until the auction ends orwhen the client system 100 quits. The transaction server 111 uses thesocket session to update, on request, all bidders for the respectivedeparture city with seat inventory status 43. In the process of buyinginventory, the client systems 100 submit purchase requests, through theHTTP server 119, which may or may not be successful. When a purchase ismade, the successful bidder is dropped from the current auction. Thecentral database server 115 is then updated, which in turn updates therespective airline host yield management system 118, through the PNRprocessor 116 and returns the confirmation of the purchase with a recapof the itinerary to the bidder's computer. (See FIG. 7).

The PNR processor 116 is connected directly to the airline's host system118, which allows it to access and manipulate specially designatedinventory for auction purposes. The database server 115, in turn,updates all the other elements of the auction. This is preferably acompletely automated process, requiring no manual intervention. In aprocess that may occur simultaneously or delayed, the accountinginformation of the bidder is updated. For example, a credit card chargeis initiated. If this is not confirmed, the inventory is returned forreuse by the airline host yield management system 118.

As transactions are completed, the database server 115 of the auctionsystem 110 provides data to one or more automated PNR processors 116, inorder build Passenger Name Records (PNR) in the airline's host system118. The credit card approvals are obtained through a credit cardverification system 117; otherwise, a PNR will not be created and theseat inventory will be returned for later auctions. While all creditcards are preferably qualified prior to the bidding process, a purchasemay nevertheless fail to confirm for a variety of reasons, such asinsufficient credit limit. The auction system 110 may manage a set ofrules for disqualifying bidders (or particular forms of payment), e.g.,in the event of unresolved payment issues.

As shown in FIG. 8, a transaction server 111 preferably directlyaccesses the airline's designated auction inventory in the airline hostyield management system through the database server 11S. If inventory isavailable, the auction will create a temporary database for eachcity-pair through which it will offer this inventory for the duration ofa four-minute auction. The airline may allocate inventory for an auctionat any time and in any quantity. Thus, the airline may release inventoryperiodically through the auction system, either uniformly or in a manneranticipated to coincide with peak demand and therefore peak pricing, orbased on sales volume and pricing made through other venues.

The system preferably implements any restrictions or rules defined bythe airline, which are initially implemented by the application software104 in the client system 100, and checked for consistency by thetransaction server 111 and/or database server 115. Typically, thetickets are non-refundable, but may be subject to penalty forpermissible change. The tickets sold may be one way, or round trip withpermissible combinations defined by rules.

To assist in scheduling, an auction bulletin board screen 5 provides aschedule of auction content and times, as shown in FIG. 2.

The default city-pair shown in the dropdown box 4 at the top of thescreen automatically displays the gateway city-pair located in theclosest proximity to the bidder's residence, as provided during theregistration process. This drop down box 4 lists all the availablegateway city-pairs as options. The bidder then selects a gatewaycity-pair on which he intends to bid.

Second, a drop down box, under the departure date heading 8, displaysthe date range of the auction currently in progress. When the bidderclicks on the arrow 45, a calendar (not shown) is displayed, from whichthe bidder will select a desired departure date. To make this selection,the bidder will click on a date shown on the calendar, and may movebetween the months by clicking on arrows displayed at the top of thecalendar. Once a departure date 8 has been selected, all availableflights 13 from this gateway, for this chosen date, will be displayed inthe window below this box.

The bidder then selects one of the departure flights 13 shown. This isaccomplished by clicking on the box 46 next to the flight listed. In around trip auction, once a date has been selected, all the valid returnflights 14 for this selected outbound flight 46 will be displayed in thewindow under the Return Dates heading 9. The auction application isdesigned to incorporate any flight rules and/or restrictions that theairline wishes to impose.

Third, the bidder will select one or several of the return flights 14shown in this window. As the bidder selects his flights, they will bedisplayed in the bottom window 15 of the selection screen. For anauction, the bidder may select any combination of departure dates andreturn flights within the auction's one-week date range up to a totaloften flights per auction. Of course, such a limit is imposed primarilyto provide an uncluttered display, and alternative displays may also beemployed.

A bidder may also make similar selections in upcoming auctions by simplyselecting a departure date 8 in another week or subsequent weeks withina 12-week time frame.

In order to reduce the number of bidders in any particular auction, thenumber of flights offered may be limited, for example, to one week ofoutbound flights and four weeks of return flights for each departingcity-pair of the airline's flight schedule.

Additionally, a bidder may choose to participate in multiple auctionssimultaneously. He may do so by returning to the top of the screen andselecting another gateway city-pair 4 and then repeating the abovesteps, or by programming a proxy bidder by selecting the proxy bidbutton 18, described below.

Displayed on the right hand side of the selection screen is a boxshowing a list of travel companions 12, the names of which werepreviously entered by the bidder when he registered. This is the defaultpassenger list. Above this list is the name of the registered auctionbidder 11. Since, in a consumer auction, the registered bidder 11 mustbe one of the passengers, this name will always be displayed asselected. If more than one passenger is traveling, the bidder mustselect his travel companions 12 by clicking on the selection box 47 nextto the passenger's name. If the passenger traveling is not shown on thedefault list, the bidder may add a travel companion by clicking on theAdd Companion button 17 located at the bottom of the screen. Clicking onthis button will display a pop-up window prompting the bidder to add thename of the additional passenger. Once completed, the bidder clicks onthe OK button and this passenger's name will be added to the travelcompanion list 12 displayed. If more than one passenger name needs to beadded, the bidder will repeat the above steps. This selection determinesthe number of seats that he will be bidding on.

Of course, other rules could be implemented to properly identify thetravelers while allowing third parties to negotiate the transaction.Thus, the rules applicable to consumers may be different from rulesapplicable to agents or aggregators. Further, bidders subject todiffering rules may participate in the same auction.

After making all his selections including travel companions, the bidderis ready to join in the auction by clicking on the Auction button 16 atthe bottom of the screen.

If he has made at least one selection originating in the date range thatis currently being auctioned, he will enter that auction, if it is stillin progress. Otherwise, he must wait for the auction to commence.

Once in an auction, the bidder will see a screen, as shown in FIG. 4,displaying all the flights 21, 22, he previously selected to bid onalong with the currently offered price 48. The number of seats stillavailable 43 may also be displayed or if that number is not specified,the bidder will see a horizontal bar 44 representing the fact that thereare seats available for that flight in that auction. In an auction for around trip, the flight pair is bid on together, and the number of seatsleft 43 may represent the lower of the inventory for the pair offlights, and the bar 44 show two components for the respective outboundand return flights.

At the top of the Auction screen is a drop-down box displaying thegateway city-pair 4 of the current auction. A countdown clock 7 appearsin the upper right corner of the screen, indicating the time remainingbefore the auction is closed, regardless of remaining inventory.

The bidder may switch from auction to auction, if he has made biddingselections from multiple gateway city-pairs and/or departure dates, byselecting the gateway city-pair 4 he wishes to view from this drop downbox. In doing so, the window will then display the auction selectionsfrom the newly selected gateway city-pair 4.

As the auction time continues to countdown to zero, the bidder willwatch the offered price 48 drop over time. Once the price has reachedthe bidder's desired price point, and if there are seats stillavailable, he will click on the Buy button 49, located to the left ofeach flight listing. Once he makes a BUY decision by selecting the buybutton 49, he will immediately be taken out of the auction and all otherselections for that auction will be deleted, thus preventing duplicativepurchases, even by proxy bidder. It is also possible to override thisfeature as necessary, by modifying the associated rule.

In any case, if the bidder wishes to make additional selections duringan auction, he may click on the Select Additional Flights 24 button atthe bottom of the auction screen. This will return him to the AuctionSelection Screen of FIG. 3, where he may choose additional flightselections. After he has completed his selections he will again click onthe auction button to return to the action.

The status of an auction is displayed in the upper right hand corner ofthe selection screen, the auction screen and the upcoming auctionsscreen. It displays the time remaining 7 in the current auction alongwith the date range of the auction 5. If a bidder does not have anyselections in the current auction or if the auction is over, the bidderwill be taken into the Upcoming Auctions screen, shown in FIG. 5, toawait the beginning of the next auction.

The Upcoming Auctions Screen contains the following components. At thetop of the screen is the drop-down box displaying the gateway city-pairs4. In this screen, this box only contains the gateway city-pairs inwhich the bidder has previously selected flights on which to bid.

Displayed under the Upcoming Auctions heading is a listing of theupcoming auctions in which the bidder has made selections 26, along withthe time that the auction will be run and the number of seats he isbidding on.

As the user moves the cursor over this information, time, date rangesand number of seats, a window box 50 on the right hand side of thescreen displays the information associated with that data. For example,if the user moves the cursor over the number of seats, the window willdisplay the names of the travelers. If the user moves the cursor overthe date range, a list of the individual flights and the flightinformation will be displayed etc.

From this screen, the bidder may select additional flights to bid on, byclicking on the select flights button 27. The bidder will be taken intothe Auction Selection Screen shown in FIG. 3, where he will make hisselections. If the bidder has made previous purchases, there will be aCurrent Itineraries button 19 on the bottom right of the upcomingauction screen. By clicking on this button 19, the bidder can review allother previous purchases that he has made through the auction.

The bidder also has the option of clicking on the Exit button 23, whichwill return him to the auction home page 1, shown in FIG. 1. This actionwill also delete any previous auction selections that have been made bythe bidder, only for an auction then currently in progress.

After a bidder has made a successful buy, he will be notifiedimmediately of his purchase. A purchase confirmation screen, shown inFIG. 7, will be displayed to him in the form of an itinerary including abreak down of the total amount of his purchase. At this time, the bidderindicates the desired delivery method 39 of the travel documents. Thecredit card reported during the registration process will be chargedwith the delivery fee and the price of the tickets. The bidder may printa hard copy of this itinerary screen for his records by selecting theprint button 42.

By clicking on the return button 41, the bidder will be taken either tothe Upcoming Auctions screen (FIG. 5) to wait for any additionalauctions in which he may have selections, or he will be taken to theAuction Selection screen (FIG. 3) allowing him to continue to makeadditional auction selections.

A unique method is provided for allowing the bidder to participate in anauction without actually being online at the time the auction is held.This is termed Proxy bidding. If a bidder is interested in participatingin an upcoming auction but will not be available to login during thetime scheduled for this auction, he may elect to submit a proxy bid. Atthe bottom of the Auction Selection screen is a button labeled Proxy Bid18, the selection of which displays a Proxy Bidding screen, shown inFIG. 6.

A proxy bid covers all selections in an auction for all gatewaycity-pairs 4. These selections 51 will be displayed at the top of theproxy bid screen along with a list of the passengers 52. In the boxdisplayed in the bottom left corner of this screen 30, the bidder willenter the price 32 he is willing to pay for his tickets. This windowalso defines the parameters under which he is willing to make this bid.This includes the number of available seats 31 broken into segments. Bymeans of a sliding scale 33, the bidder can specify a range ofacceptable bidding prices based on his default price 32. This allows thebidder the flexibility to participate in the auction bidding over arange of prices and available seats.

For example, the bidder may determine a fixed proxy bid price, or aproxy bid price which increases with decreasing available inventory. Thebidder may select both the seat inventory segments and price increments.The default system provides a linear price increment over constant sizesegments of remaining seats.

Once the bidder is satisfied with the pricing options he has selected,reviewed his flight options and verified the passenger names, he has twochoices. He can submit his proxy bid by clicking on the Submit button 35or he may cancel his proxy selections by selecting the cancel button 34,which will return him to the Auction Selection screen, as shown in FIG.3. If the bidder elects to continue with his proxy bid, he will click onthe Submit button 35. This will transmit his proxy bid information to aproxy server 113 located proximate to the auction system 110. This proxyserver 113 is dedicated to storing all proxy bidding data andfunctioning as an absentee bidder by participating in individualauctions on behalf of its bidders. This proxy presents a number ofadvantages to the bidder. Since it is proximate to the transactionserver 111, latencies will be short. Other than conflicts from otherproxy bidders, a proxy bid will almost always be submitted and acceptedbefore a live bid under the same terms.

Any successful purchases resulting from a proxy bid are final and cannotbe canceled. The proxy server will notify the bidder of his successfulbid by means of an email. Tickets purchased by means of a proxy bid willbe sent to the bidder, for example, via overnight mail or by otherselected or default shipping option.

Therefore, the proxy bid provides the option for a sliding scale bidbased on remaining inventory. The less remaining inventory, the higherthe bid price. Thus, the bidder may select a certain strategy tooptimize the price paid.

FIG. 9 describes an algorithm for determining a current price of a seatin a particular auction based on time increment (tick), price spread(initial price minus lowest acceptable price), final price, total time(total ticks), previous price (which is, according to this embodiment,determined adaptively during the course of the auction), total seatssold, and original inventory.

This formula is:

[(TOTAL TICK−CURRENT TICK)/TOTAL TICK×(OPENING PRICE−FINAL PRICE)+FINALPRICE]+[(CURRENT TICK/TOTAL TICK)×(OPENING PRICE−PREVIOUSPRICE)]×[((TOTAL SEAT SOLD×(OPENING PRICE/FINAL PRICE+1))×(TOTALTICKS−(CURRENT TICK−1)/TOTAL TICKS)/ORIGINAL INVENTORY]

Although various preferred embodiments of the present invention havebeen described herein in detail, it will be appreciated by those skilledin the art, that variations may be made thereto without departing fromthe spirit of the invention or the scope of the appended claims.

What is claimed is:
 1. An auction method, comprising: (a) identifyingauction parameters comprising at least one price rule and an auction endrule; (b) transmitting an identification of the lot, and the auctionparameters from an auction server system to a plurality of bidders atremote locations through a packet switched computer network; (c)receiving bids from the bidders at the remote locations, from theplurality of bidders at the remote locations, through the packetswitched computer network, the bids each being automaticallytime-stamped by the bidder; and (d) verifying compliance with theauction parameters, and determining a winning bidder based on thereceived bids and the automatic time-stamp.
 2. The auction methodaccording to claim 1, wherein the auction comprises an ascending priceauction.
 3. The auction method according to claim 2, wherein each bidcomprises bid price information.
 4. The auction method according toclaim 1, wherein the auction comprises a descending price auction. 5.The auction method according to claim 4, wherein bid price informationis automatically determined by the auction server system.
 6. The auctionmethod according to claim 1, wherein the auction server system isconfigured to support, in a single auction, bidders which interact withthe auction server system through web browsers supporting HTML andthrough applets.
 7. The auction method according to claim 1, wherein atleast a portion of the bidders at the remote locations communicatethrough wireless mobile devices.
 8. The auction method according toclaim 1, further comprising analyzing stored bid pattern activity datato determine a set of auction parameters.
 9. The auction methodaccording to claim 8, wherein an offering price is changed over time ina pattern adaptive to the defined set of auction parameters.
 10. Theauction method according to claim 1, further comprising providing aninterface to permit a bidder to implement a bidder agent whichautomatically communicates bids on behalf of the bidder.
 11. The auctionmethod according to claim 1, wherein the auction end rule comprisesending the auction upon the earlier of an expiration of a time for theauction, and exhaustion of availability of a subject of the auction. 12.An auction method, comprising: (a) defining at least one lot to beauctioned, comprising at least one unit in the lot, and associatedauction parameters comprising at least a price rule and an auction endrule; (b) communicating the associated auction parameters from anauction server to a plurality of remote locations; (c) processing theauction parameters at each remote location to generate in dependencethereon a locally-defined display, comprising a displayed count-downclock, and an identification of the at least one lot; (d) communicatingbids from the plurality of remote locations to the auction server, eachbid comprising at least an automatically generated time-stamp; and (e)producing an output representing at least one winning bid based on thecommunicated bids received from the plurality of remote locations andthe respective time-stamps.
 13. The method according to claim 12,wherein the price rule defines a descending price auction.
 14. Themethod according to claim 12, wherein the price rule defines adescending price auction.
 15. The method according to claim 12, whereinthe auction server communicates with bidders through at least protocols,a first protocol comprising HTML adapted for communication with a webbrowser, and a second protocol being adapted for communication with anapplet.
 16. The method according to claim 12, wherein the auction serveris configured to communicate with mobile wireless devices through awireless application protocol.
 17. The method according to claim 12,further comprising synchronizing a bidder clock with the auction serverclock.
 18. An auction method, comprising: (a) identifying an auction,having an auction price parameter and an auction termination parameter;(b) transmitting an identification of the auction and associated auctionprice parameter and an auction termination parameter from an auctionserver to a plurality of bidder locations; (c) receiving bids from theplurality of bidder locations, each bid comprising at least anautomatically generated time-stamp; (d) modifying the auction price overtime, wherein said modifying is responsive to a pattern of bidsreceived; and (e) terminating the auction in accordance with the auctiontermination parameter, and outputting information representing at leastone winning bidder responsive to at least the time-stamp.
 19. Theauction method according to claim 18, wherein the auction servercommunicates with bidder locations through at least HTML and throughapplets.
 20. The auction method according to claim 18, wherein at leasta portion of the remote locations comprise wireless mobile devices.